Skip to main content

EVPN Part 6: Kiến Trúc Routing Table Nội Bộ

Loạt EVPN (7 phần): 1. Vì sao cần EVPN & Fabric · 2. MAC VRF & IP VRF · 3. Route Types & MAC/IP · 4. Inter-VNI & Multi-Homing · 5. Cấu hình & Troubleshooting · 6. Routing Table nội bộ · 7. Multi-Site RT & Route Leak (sắp đăng)

Phần 6/7 trong loạt EVPN: đọc sau Phần 5: Cấu Hình, Kiểm Tra & Xử Lý Sự Cố. Từ đây trở đi là góc nhìn production: giải thích những khái niệm dễ nhầm khi đọc config thực tế trên thiết bị đang chạy multi-tenant, multi-site. Khác với Phần 5 trình bày song song bốn vendor, Phần 6 và 6 đi theo Junos, vì ở mức chi tiết này mỗi vendor đặt tên bảng route và tổ chức cấu hình rất khác nhau; logic bên dưới thì vẫn là logic EVPN chung đã học ở Phần 1 đến Phần 4. Đọc theo thứ tự, vì mỗi phần dựng tiếp trên phần trước. Toàn bộ tên site, tên VRF, giá trị RD/RT/IP trong Phần 6-7 đều là giá trị minh họa, không phải cấu hình thật của bất kỳ hệ thống nào.

Năm phần trước đã trả lời "EVPN hoạt động như thế nào về mặt khái niệm". Câu hỏi của phần này khác hẳn: khi gõ show route table bgp.evpn.0 trên một switch thật đang chạy production, output đó thực chất là cái gì, và vì sao có tới bốn, năm loại bảng route khác nhau chứ không phải một? Đây là câu hỏi mà rất nhiều kỹ sư mới tiếp xúc EVPN thực tế bị vấp, không phải vì khó, mà vì tài liệu vendor thường liệt kê tên bảng mà không giải thích quan hệ giữa chúng.

Hai câu hỏi cốt lõi mà phần này trả lời:

  1. Một route EVPN đi từ BGP vào tới bảng mà data plane đọc để forward phải qua những bảng trung gian nào, và vì sao không gộp hết vào một bảng cho gọn (Mục 1, 2)?
  2. Cơ chế nào quyết định route nào được vào MAC-VRF hay IP-VRF, và vì sao virtual-router lại không hề có cơ chế đó (Mục 3, 4)?

Mục lục​

Hai mục đầu dựng nền: route nằm ở bảng nào và hai loại VRF khác nhau ra sao. Hai mục sau trả lời cơ chế lọc: ai quyết định route được vào bảng nào.

1. Routing Tables Trong EVPN — bgp.evpn.0, evpn.0, inet.0​

Đọc phần này trước: nếu không hiểu route nằm ở bảng nào, mọi phần còn lại sẽ khó theo dõi.

Mental Model: Sân bay quốc tế​

Hình dung một sân bay quốc tế lớn, nơi hành khách từ khắp nơi đổ về và phải qua từng trạm kiểm soát trước khi thực sự "vào" được thành phố:

  • bgp.evpn.0 = khu vực nhập cảnh quốc tế. Tất cả hành khách (route EVPN) từ mọi hãng bay (BGP peer) đều hạ cánh ở đây trước tiên. Chưa ai được phân loại, chưa ai biết mình sẽ đi phòng nào; đây đơn thuần là "hòm thư chung" của BGP.
  • VRF_XXXX.evpn.0 = khu vực hải quan riêng của từng hãng bay. Hành khách đã được phân loại (RT khớp thì mới lọt vào đây) nhưng vẫn đang mang đầy đủ giấy tờ gốc (metadata EVPN: VNI, RT, GW IP, VTEP), chưa sẵn sàng bước ra ngoài.
  • VRF_XXXX.inet.0 = cửa ra, nơi hành khách đã đổi xong giấy tờ và sẵn sàng lên xe. Route ở đây đã được chuyển đổi (convert) sang dạng IPv4 prefix thông thường, và đó là bảng mà data plane đọc để forward packet.
Routing Table Pipeline in EVPNbgp.evpn.0Shared inbox: every routeEVPN (Type 1-5), unfiltered"International arrivals"RT filterVRF_100.evpn.0Routes that passed the RT filterstill carrying EVPN metadata"Private customs desk"convertVRF_100.inet.0Ordinary IPv4 prefixesThe data plane reads this table"Ready to board"Real flow: a Type 5 route through the pipelineRemote VTEP sends Type-5: {prefix=10.2.0.0/16, VNI=51000, RT=target:64001.0:1}bgp.evpn.0 (unfiltered) → RT filter → VRF_100.evpn.0→ auto-convert → VRF_100.inet.0:10.2.0.0/16 via 10.0.0.2 [EVPN/170] ← tag "protocol evpn"

Bảng routing tables liên quan đến EVPN​

Routing TableNội dung và vai trò
bgp.evpn.0Tất cả EVPN BGP route (Type 1-5) từ mọi BGP peer — chưa filter, chưa thuộc instance nào. "Inbox chung"
default.evpn.0EVPN route của MAC-VRF (switch-options) — chính là bgp.evpn.0 đã qua vrf-import của switch-options. Dùng để build MAC table, ARP table, VTEP table
VRF_XXXX.evpn.0EVPN route đã pass RT filter, thuộc một VRF cụ thể — trung gian, vẫn còn metadata EVPN, chưa convert
VRF_XXXX.inet.0Bảng IPv4 của VRF — data plane dùng để forward. Chứa route từ nhiều nguồn, phân biệt bằng nhãn "protocol"

Vì sao phải có bgp.evpn.0 riêng, không nhập chung vào inet.0?​

Câu trả lời nằm ở chỗ Type 5 EVPN route mang theo những trường metadata mà một route BGP/IP thông thường không có: VNI, RT, GW IP, VTEP address. Không thể cài thẳng những route này vào inet.0 như một route BGP bình thường được, vì inet.0 chỉ hiểu prefix/next-hop/metric, không hiểu "VNI để encapsulate VXLAN" là gì.

bgp.evpn.0 tồn tại để giữ nguyên dạng route EVPN với đầy đủ metadata, và RT filter dùng chính metadata này để quyết định route thuộc VRF nào. Sau khi lọc xong, route mới được convert sang dạng prefix đơn giản trong inet.0. Nếu bỏ qua bước tách bảng này, hệ thống sẽ không còn biết một route cần forward theo kiểu EVPN (đóng gói VXLAN với đúng VNI) hay theo kiểu BGP thông thường, nên VNI cần thiết để encapsulate sẽ bị mất, khiến traffic không đi được.

Cần nhớ: nhãn protocol evpn hay protocol bgp gắn trên một route trong VRF.inet.0 cho biết route đó đến từ đâu, và nhãn đó ảnh hưởng trực tiếp đến cách viết policy, như sẽ thấy ở phần sau.

2. MAC-VRF vs IP-VRF — Hai Thế Giới Khác Nhau​

Tại sao cần phân biệt: cấu hình EVPN trên Junos chia làm hai khu vực riêng biệt, switch-options và routing-instances, phục vụ hai mục đích khác nhau. Nhầm lẫn hai thứ này là nguồn gốc của rất nhiều lỗi khó debug trong thực tế.

Bản chất của hai forwarding space này, cùng phép ví von sổ địa chỉ từng tòa nhà so với bản đồ quy hoạch toàn khu, đã nằm ở Phần 2, Mục 1 kèm bảng so sánh đầy đủ theo từng tiêu chí. Mục này không nhắc lại, mà trả lời đúng câu hỏi mới phát sinh khi mở một file cấu hình Junos thật: hai forwarding space đó được khai ở hai khu vực nào của config, và mỗi khu vực chịu trách nhiệm những route type nào.

Trong cấu hình Junos​

MAC-VRF nằm trong switch-options, xử lý Type 2 (MAC/IP), Type 3 (BUM list), Type 1 (ESI), và xuất ra MAC table/ARP table/VTEP table:

switch-options {
    vtep-source-interface lo0.0;
    route-distinguisher 10.0.0.1:1;
    vrf-target target:64001.0:1;
    vrf-import OVERLAY_IMPORT;    ← filter EVPN L2 route (Type-1/2/3)
}

IP-VRF nằm trong routing-instances, chỉ xử lý Type 5 (IP Prefix), xuất ra bảng VRF.inet.0:

routing-instances {
    VRF_100 {
        instance-type vrf;
        route-distinguisher 10.0.0.1:100;
        vrf-target target:64001.0:100;
        vrf-import VRF_IMPORT_POLICY;  ← filter L3 route (Type-5)
    }
}
MAC-VRF and IP-VRF — Connected by IRBMAC-VRF (switch-options)Type 2: learns MAC/IP · Type 3: BUM list · Type 1: ESI→ MAC table, ARP table, VTEP table"Seating chart"IRB interface: the bridgeIP-VRF (routing-instances)Type 5: prefix routing · BGP: routes from GW or peer→ VRF.inet.0 routing table"Street map"

Quy tắc nhớ: switch-options = mọi thứ Layer 2 EVPN. routing-instances vrf = mọi thứ Layer 3 routing. IRB interface là cầu nối duy nhất giữa hai thế giới, đúng khái niệm IRB đã học ở Phần 1 và Phần 4.

3. switch-options vrf-import và EVPN — Tại Sao Liên Quan?​

Đây là phần dễ nhầm nhất. Nhìn vào config, EVPN chạy trên BGP, switch-options trông như cấu hình L2 switching thuần túy, còn vrf-import nghe như tính năng riêng của VRF layer 3. Ba thứ này liên quan gì đến nhau?

Mental model: BGP là bưu tá, vrf-import là hộp thư có bộ lọc​

Không có vrf-import: BGP nhận route EVPN từ VTEP ở xa, đặt vào bgp.evpn.0, rồi... dừng lại ở đó. BGP tự nó chỉ là "bưu tá": nó không biết route này cần đi tiếp đâu. MAC table vẫn trống, không thể forward tới remote host.

Có switch-options vrf-import: route từ bưu tá (BGP) đi vào hộp thư chung (bgp.evpn.0), rồi vrf-import chạy một phép kiểm tra: "RT này tôi có nhận không?" Nếu có, route được cài vào MAC-VRF (MAC table, ARP cache); nếu không, bị bỏ qua. Chỉ sau bước này, data plane mới có đủ thông tin để forward tới remote host.

Luồng đầy đủ — từ BGP đến forward​

Đi theo đúng một route Type 2 từ lúc nó tới thiết bị cho đến lúc data plane dùng được nó:

  1. Remote VTEP gửi EVPN UPDATE. Route mang {MAC=AA:BB:CC, IP=10.1.1.10, VTEP=10.40.0.1, VNI=1000, RT=SITEB_RT}.
  2. Route hạ cánh ở bgp.evpn.0. Mọi route EVPN từ mọi peer đều vào đây trước, chưa qua bất kỳ bộ lọc nào.
  3. switch-options vrf-import chạy policy OVERLAY_IMPORT. Term SITEB match from community SITEB_RT nên route được accept. Không có term nào match thì route dừng lại ở bước 2 và không bao giờ tới được MAC table.
  4. MAC-VRF được cập nhật. MAC table ghi AA:BB:CC → VTEP 10.40.0.1, VNI 1000; ARP cache ghi 10.1.1.10 → MAC AA:BB:CC.
  5. Data plane bắt đầu dùng được. VM cục bộ ARP hỏi 10.1.1.10, Leaf proxy-reply bằng MAC AA:BB:CC; VM gửi packet, Leaf tra MAC table thấy VTEP 10.40.0.1 và đóng gói VXLAN với VNI 1000.
Where A Route Can Get Stuck On Its Way To The Data Plane1. Remote VTEP sends an EVPN UPDATEType 2: MAC=AA:BB:CC, VTEP=10.40.0.1, VNI=1000, RT=SITEB_RT2. The route lands in bgp.evpn.0every EVPN route from every peer, nothing filtered yet3. switch-options vrf-import runs OVERLAY_IMPORTterm SITEB matches the community and accepts the route4. MAC-VRF is updatedMAC table and ARP cache now hold the remote entry5. Data plane can finally forwardproxy-ARP locally, then VXLAN to 10.40.0.1 with VNI 1000nomatchMiss step 3 and the route simply stops at bgp.evpn.0: visible in BGP, absent from the MAC table

Vì sao nằm trong switch-options chứ không phải protocols bgp?​

protocols bgp chỉ đóng vai trò "bưu tá": nhận, lưu, chuyển tiếp, không quan tâm route là EVPN hay unicast BGP thông thường, và không hề có khái niệm "MAC table" hay "VTEP". Ngược lại, switch-options chính là "chủ nhà" của MAC-VRF, nên nó quyết định route nào được cài vào forwarding table. Về bản chất, EVPN là instance sở hữu logic; BGP chỉ là phương tiện vận chuyển. Nguyên lý này lặp lại y hệt ở phía routing-instances VRF: BGP vẫn chỉ là transport, còn vrf-import trên routing-instance mới là bên quyết định route nào vào IP-VRF.

4. VRF vs Virtual-Router — Khả Năng Lọc Route Khác Nhau​

Tại sao cần biết: một số thiết kế dùng virtual-router (ví dụ đặt tên GW_VR1) làm gateway trung tâm thay vì một vrf thông thường. Virtual-router không có vrf-import/vrf-export, nên nếu không biết trước sẽ mất thời gian tìm cấu hình RT ở một chỗ không hề tồn tại.

So sánh 3 loại instance​

switch-options (MAC-VRF)routing-instances vrf (IP-VRF)routing-instances virtual-router
vrf-import/exportCóCóKhông có
route-distinguisherCóCóKhông có
RT (Route Target)CóCóKhông có
Tham gia VPN signalingEVPN L2EVPN L3 / VPNv4Không
Filter route bằngvrf-importvrf-importBGP import/export policy
Dùng choEVPN L2L3 VPN, DCIIsolated routing table

Vì sao Virtual-Router không có vrf-import?​

vrf-import/vrf-export là cơ chế gắn liền với khái niệm Route Target, mà RT lại là một khái niệm thuộc về L3 VPN (RFC 4364) và EVPN (RFC 7432). Virtual-router, theo thiết kế, không tham gia VPN signaling: nó chỉ đơn thuần là "một bảng định tuyến tách biệt", giống một VRF cơ bản không có phần VPN đi kèm. Do đó nó không có RT, và cũng không cần vrf-import.

Route của virtual-router được lọc bằng BGP policy trực tiếp tại chính BGP session, đơn giản hơn nhưng kém linh hoạt hơn (không filter được theo RT/community, chỉ filter theo prefix, as-path, v.v.).

Only The Two VPN Instances Can Filter By Route Targetswitch-optionsMAC-VRFvrf-import: yesroute-distinguisher: yesRoute Target: yesfilters withvrf-importEVPN L2 (Type 1/2/3)routing-instances vrfIP-VRFvrf-import: yesroute-distinguisher: yesRoute Target: yesfilters withvrf-importEVPN L3 (Type 5), VPNvirtual-routerisolated tablevrf-import: noneroute-distinguisher: noneRoute Target: nonefilters withBGP policy onlyno VPN signallingRoute Target belongs to VPN signalling, so an instance that joins no VPN has nowhere to put a vrf-import
# GW_VR1 trên router GW (minh họa) — KHÔNG dùng vrf-import
routing-instances {
    GW_VR1 {
        instance-type virtual-router;
        interface irb.100;         # gateway cho VRF_100
        interface irb.200;         # gateway cho VRF_200
        interface ae11.999;        # uplink đến interconnect
    }
}

# Filter route qua BGP policy — đặt trong protocols bgp của GW_VR1
protocols bgp {
    group IBGP_TO_SPINE {
        neighbor 10.10.0.1 {            # Spine
            import GW_VR1_IMPORT;       # BGP import policy thay cho vrf-import
            export GW_VR1_EXPORT;       # BGP export policy thay cho vrf-export
        }
    }
}

GW_VR1_IMPORT/GW_VR1_EXPORT đóng vai trò logic tương tự vrf-import/vrf-export, chỉ khác là áp dụng ngay tại tầng BGP session thay vì tại tầng routing-instance.

Nguồn tham khảo​

  • Route Distinguisher và Route Target, cùng cơ chế vrf-import/vrf-export bắt nguồn từ đó, là khái niệm của BGP/MPLS IP VPN — RFC 4364.
  • MAC-VRF và IP-VRF trong EVPN được định danh theo Route Distinguisher/Route Target — RFC 7432.
  • IRB, cầu nối duy nhất giữa hai forwarding space nói ở Mục 2 — RFC 9135.

Tên bảng route (bgp.evpn.0, default.evpn.0, <instance>.evpn.0, <instance>.inet.0) cùng cú pháp switch-options/routing-instances trong phần này theo Junos. Tên site, tên VRF và mọi giá trị RD/RT/IP đều là giá trị minh họa.

Tiếp theo: Phần 7, Multi-Site RT Pattern & Route Leak Trong Thực Tế (sắp đăng). Phần đó lấy đúng cơ chế vrf-import ở Mục 3 trên làm nền, rồi mở rộng ra nhiều site và nhiều tenant cùng lúc.